home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group92c.txt
/
000102_icon-group-sender _Fri Nov 13 05:19:21 1992.msg
< prev
next >
Wrap
Internet Message Format
|
1993-01-04
|
2KB
Received: by cheltenham.cs.arizona.edu; Tue, 8 Dec 1992 09:51:52 MST
Date: 13 Nov 92 05:19:21 GMT
From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (President Clinton Jeffery)
Subject: Re rationale for sortf()
Message-Id: <199211130519.AA22161@chuckwalla.cs.arizona.edu>
Sender: icon-group-request@cs.arizona.edu
To: icon-group@cs.arizona.edu
Status: R
Errors-To: icon-group-errors@cs.arizona.edu
Jerry Nowlin writes:
> You can define tables with field names as key and the record index as value
> and just use that in place of field name arguments to sortf(). When you
> change record definitions you would have to change tables values. This
> won't help with Idol unfortunately. Maybe Idol could put extra fields at
> the end of records to avoid obscuring known index values?
An interesting thought. There is no reason the two "extra fields" could not
be put at the back. But current default behavior notwithstanding, objects
are not supposed to be transparent and allow any old function to access
their internal fields; a sortf() that would be technically correct for Idol
would call a procedure (method, really) to access the key, and there are real
technical reasons why sortf() doesn't call back out to an Icon procedure (or
Idol method) in the present implementation -- none of Icon's built-in
functions do that, in fact. Writing a built-in Icon function that calls
procedures is our user-grailquest for the week; in the meantime sorters of
lists of objects would do well to consider adapting Bob Alexander's elegant
isort procedure from the Icon program library.